1. Field of the Invention
The invention concerns a method for assisting the development of a set of communicating automata implemented either as software in a data processing machine or as a hardwired logic circuit. The method is more particularly directed to the design of telecommunication systems which includes call processing applications for a switching center. A call processing application runs in real time and comprises a large number of communicating automata processing a plurality of interleaved messages.
The development of any such set of automata involves: firstly, a human designer; secondly, a development machine which is a general-purpose computer on which software for assisting the development of a set of communicating automata is installed; and thirdly, a target machine on which the software implementing the set of communicating automata will be installed. In the case of a telecommunication system, the target machine is the multiprocessor control unit of a switching center, for example. In this case each automaton is implemented entirely in one processor but one processor may support a plurality of automata.
2. Description of the Prior Art
The designer of a set of communicating automata constituting a call processing application, for example, starts with a defined set of functions that the application is to implement. The behavior of each function will be defined by one automaton. The designer is familiar with the external and internal interfaces of the set of automata. The development of a set of communicating automata comprises four stages:
writing a specification for a set of communicating automata, on the basis of the required functions, the communicating automata being intended to be implemented as software in the target machine but to be modeled on the development machine; PA0 analyzing the automata and their communications via their interfaces using the development machine model; PA0 implementing the communicating automata as software in the target machine; PA0 validating the software in the target machine. PA0 the places and an initial configuration of the tokens, for the initial global state; and PA0 transitions associated with the places and with events, each event firing or being the consequence of a transition and the events representing the interface between the application and its external environment. PA0 it is very difficult for the designer to describe the overall behavior of the application using only one Petri net; PA0 the exhaustive analysis of the net requires development machine computer time and memory capacity which can quickly become prohibitive; PA0 debugging is difficult and entails repeating the analysis many times. PA0 supplying to a development machine a description of initial elementary Petri nets respectively modeling partial behaviors of each function by describing events which fire or are consequences of transitions in each initial Petri net and assigning a label to each transition dependent on at least one event, each event firing or being a consequence of said transition, said events representing interfaces external to the set of automata, inter-automaton interfaces and interfaces between the initial nets; PA0 verifying on said development machine that each initial net has the required properties; PA0 supplying to said development machine a description of constraints between initial nets representing the behavior of the environment external to the set of automata; PA0 notifying to said development machine a plurality of nets to be combined and a communication mode to cause it to combine initial Petri nets with each other or with Petri nets replacing initial nets previously combined or to combine nets replacing initial nets previously combined, each combination being effected by causing to communicate at least two nets using the labels of their transitions in the notified communication mode, which is chosen from the following modes: PA0 a synchronous mode; PA0 an asynchronous mode; PA0 a pseudo-synchronous mode in which events constituting communication with the environment external to the net resulting from the combination are synchronous with the environment external to the nets to be combined and asynchronous within the nets to be combined, each pseudo-synchronous mode combination allowing for internet constraints; PA0 causing said development machine to verify that the net resulting from said combination has the required properties; PA0 supplying to the development machine a description of modified initial nets replacing initial nets to be combined if the net obtained by combining the initial nets does not have the required properties; and PA0 notifying again to said development machine a plurality of nets to be combined and a communication mode to cause it to carry out a series of combinations and verifications until Petri nets are obtained having the required properties and respectively modeling each communication between two inter-automaton interfaces or between an external interface and the environment external to the set of automata and each automaton of the set. PA0 is a consequence of one of the transitions and fires another transition; or PA0 is a common consequence of the transitions; or PA0 fires all the transitions. PA0 linking first and second nets to be combined by means of one queue in each communication direction; and PA0 imposing temporary constraints on the communication protocol using the two queues throughout the duration of the verification of the required properties of the resulting net obtained by combining the two nets to be combined and the two queues. PA0 linking the nets using a single queue having a plurality of inputs respectively connected to an output of each of the nets to be combined and a plurality of outputs respectively connected to an input of each of the nets to be combined; PA0 imposing a permanent constraint giving events from said queue priority over events from interfaces external to the net obtained to fire transitions in the nets to be combined; and PA0 imposing temporary inter-net constraints only during the verification of the properties required of the Petri net modeling the behavior of an automaton and consisting in adding conditions for firing transitions of one of the nets to be combined, these conditions relating to the status of the other nets to be combined and representing the behavior of the environment of the resulting net. PA0 a first stage comprising: combining nets two by two using the synchronous communication mode to obtain Petri nets replacing initial nets and comprising at most one interface external to an automaton; verifying that the nets obtained have the required properties; and repeating the first stage for nets which have been combined where the resulting net does not have the required properties; PA0 a second stage comprising, for each interface external to an automaton: combining two by two using the asynchronous communication mode Petri nets obtained from the first stage and having a common inter-automaton interface or interface external to the set of automata to obtain from each such combination a Petri net modeling communication between two inter-automaton interfaces or between an interface external to an automaton and the environment of the set of automata; verifying that the nets obtained have the required properties; and repeating the first stage for nets that have been combined and for which the resulting net does not have the required properties; and PA0 a third stage comprising: using the pseudosynchronous communication mode to combine Petri nets obtained from the first stage and validated by the second stage allowing for inter-initial net constraints representing the behavior of the environment external to the set to obtain for each automaton a Petri net modeling the function of said automaton, in particular communication between the nets obtained from the first stage; verifying that the nets obtained have the required properties; and repeating the first and second stages for nets which have been combined and for which the resulting net does not have the required properties.
It is known to use formal description techniques to design a set of communicating automata because of the powerful resources that they offer. In particular, use is made of certain specialized languages whose semantics are based on mathematical models. These languages also have provision for some verification, but the methods of using these languages are not well suited to highly complex systems such as telecommunication systems.
The Petri net modeling technique is described in the article: "Modelling and Analysis of Communication and Cooperation Protocols Using Petri nets Based Models" North Holland Publishing Company Computer Nets 6 (1982) pages 419-441.
The Petri net technique is an extension of the finite state sequential automaton technique using state and transition concepts. A transition models the passage of the system from a stable state to another stable state. The novelty of Petri nets is essentially that transitions no longer link global states of a system but partial states (called "places") enabling synchronization to be expressed. A number of tokens can exist in these places. Each configuration of the tokens represents a different global state. The Petri net technique can represent a set of a large number of states and a large number of transitions of an automaton and in particular synchronization between automata.
If the Petri net technique is used to develop an application, the specification for the application consists in a description in the form of a Petri net of:
Analysis entails verifying properties required by the designer, in particular the overall consistency of the resulting Petri net, that is to say that it has the minimal properties of a Petri net, and looking for constantly true properties called invariants. An analysis is exhaustive if it consists in a search for all the states, in particular to verify that each state is reachable and that each transition is living. The search for invariants verifies the Petri net structure and determines certain properties specific to the modeled application.
The set of reachable states is called a reachability graph and constitutes an automaton representing the application to be developed.
Implementation on the target machine follows on directly from the modeling in Petri net form during the specification stage, in so far as synchronization is concerned. It remains to write series of instructions representing actions associated with the transitions of the Petri net model.
Validating the software entails defining and then executing test sets. These are conventionally defined by the designer.
The known method has the following drawbacks when it comes to developing a complex application comprising a large number of places and a large number of transitions:
An object of the invention is to propose a method for assisting the development of a set of communicating automata which is free of the above drawbacks.